Перейти к основному содержимому

1.26. Этапы карьерного роста в IT

ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Всем

Этапы карьерного роста в IT

Этапы карьерного роста в IT​

Джуниор​

Когда человек вот только-только начинает свой путь в IT, его называют джуниором. Это слово уже давно стало частью профессионального языка индустрии. Новичок в IT - это человек, который ещё не имеет практического опыта работы в команде, но уже обладает базовыми техническими знаниями. Он может уметь писать простые программы, понимает основы алгоритмов, знает хотя бы один язык программирования и умеет работать с Git. Обычно это выпускники курсов, студенты, или люди, которые самостоятельно освоили первые навыки. Иногда к новичкам относят даже тех, кто уже получил первую работу, но пока не прошёл этап адаптации и не начал решать задачи самостоятельно. В этот период он всё ещё остаётся «в обучении», хотя формально уже числится сотрудником.

Как люди себя чувствуют на первых порах? На старте многим кажется, что они знают слишком мало, и это нормально. Почти все, кто сейчас работает в IT, через это прошли.На первых порах легко потеряться в терминах, не понять многие вещи и как вообще начать работать с чужим проектом.

Часто возникает ощущение, что все вокруг говорят на другом языке, используют множество сложных англицизмов, сокращений. Страх сделать ошибку, получить критику, желание угодить коллегам, постоянное сравнение себя с другими - всё это естественные эмоции. Но важно помнить, что никто не ждёт от джуниора идеального знания, ведь его задача - учиться, задавать вопросы и не бояться просить помощи.

Слово junior пришло к нам из английского языка и буквально означает «младший». В IT-сфере так стали называть младших разработчиков, чтобы отделить их от более опытных специалистов - middle и senior.

Эта система деления на уровни возникла в крупных компаниях, где нужно было удобно распределять нагрузку и ответственность. Джуниор получает поддержку, миддл уже может работать почти самостоятельно, а сеньор берёт на себя стратегические решения и управление. Такие уровни помогают строить понятную карьерную лестницу и оценивать прогресс сотрудников. Поэтому junior - это этап, на котором учатся, ошибаются, растут и становятся лучше.

С чего обычно начинают карьеру? Большинство людей начинают с обучения - онлайн-курсов, книг, видеоуроков. Среди молодёжи популярно именно видеообразование, когда можно узнать по любому инструменту или понятию кучу уроков на YouTube. Сейчас существует множество доступных источников для изучения программирования, где можно пройти структурированное обучение.

После теории приходит практика - создание проектов, участие в open-source, хакатонах и прочем. Но это уже дело каждого, в основном люди просто пишут код и работают. Именно практика позволяет набраться опыта и собрать своё первое портфолио, после чего придёт время первого интервью и первой работы. Кто-то начинает с неоплачиваемых стажировок, кто-то с фриланса.

В IT огромное количество направлений, и джуниор может выбрать себе любую дорогу:

  • фронтенд-разработчик;
  • бэкенд-разработчик;
  • фуллстек-разработчик;
  • QA-инженер (тестировщик);
  • DevOps-инженер;
  • аналитик данных;
  • бизнес-аналитик;
  • системный аналитик;
  • разработчик мобильных приложений;
  • системный администратор.

Каждое из направлений требует разного набора знаний, но у всех джуниоров много общего - им всем нужно познать основы. В первую очередь, разбираться в протоколах, логике, и подкрепиться практикой.

Важно отметить, что в крупной серьёзной компании будут более строгие требования к программисту junior - базовые понимания языка программирования, опыт работы с Git, умение писать чистый и понятный код, знания основных принципов разработки, например SOLID, и даже участие в проектах. Но это обусловлено довольно высоким уровнем заработной платы - ведь никто не захочет платить большие деньги программисту, который не знает программирование?

Аналитикам, тестировщикам чуть проще - им больше нужно сфокусироваться на умениях анализировать, декомпозировать задачи и различных софт-навыках. Системным администраторам важно разбираться в операционных системах и уметь работать с железом.

Но так не везде - некоторые организации используют другой подход, высматривая именно хороших людей в первую очередь, ориентируясь на софт-скиллы, с перспективой обучить всем необходимым хард-скиллам. Такие могут не выставлять требования к знанию языков и опыту работы на проектах, поэтому новичку следует ориентироваться на такие компании, или повышать свои навыки.

На работе джуниоры выполняют более простые задачи, которые требуют меньше самостоятельности, и чему-то могут научить. Это небольшие баги, простые фичи по готовым техническим заданиям, тесты, документация, внедрение сторонних библиотек, а порой и выполнение задач вместе с ментором-наставником.

Джуниору не обязательно знать архитектурные паттерны, масштабирование сервисов, идеальный код, особенности деплоя или весь стек технологий компании. Всему этому можно научиться только со временем. Главное - не бояться спрашивать, учиться на ошибках и двигаться вперёд. Переход на другую ступень обычно занимает около двух-пяти лет. Всё зависит от индивидуальных особенностей самого человека, его навыков, способностей, целей, везения и компании.

Миддл​

Когда человек проходит начальный этап карьеры и уже не джуниор, но ещё не сеньор - он становится миддлом. Это важный переходный этап в жизни разработчика, так как на этом уровне уже умеем работать почти самостоятельно, берём на себя ответственность за более сложные задачи и начинаем влиять на команду. Но при этом ещё далеко до эксперта и многое предстоит выучить.

Миддл - это специалист, который имеет 2-5 лет опыта работы и уже способен выполнять большинство задач без постоянного контроля. Он понимает, как устроен проект, может читать чужой код, писать свой - так, чтобы его было легко поддерживать. Миддл не только выполняет задачи, но и начинает видеть общую картину - как работает система, зачем нужна та или иная архитектура, и как принимаются технические решения. Он уже не новичок, но не руководит проектами, однако может взять на себя модуль, дать советы коллегам, и даже помочь джуниору освоиться.

Почему миддл не старший и почему не младший? Сеньор отвечает за стратегию, принимает ключевые решения и влияет на архитектуру, понимает бизнес-цели, тогда как миддл этим пока не занимается. Его задача - быть надёжным звеном в цепочке, делать то, что ему поручено, но уже с высоким качеством и пониманием контекста. В то же время миддл уже не зависит от постоянной помощи. Он не боится брать задачи, которые занимают несколько дней. Он знает, где найти информацию, как гуглить правильно, как читать документацию и объяснять свои решения. Он стал самостоятельным, но ещё не лидером.

На этом этапе часто возникает ощущение «я уже знаю достаточно, но ещё недостаточно», из-за чего возникает спектр эмоций - от парадокса до стыда. Это нормально, и многие миддлы задаются вопросами «Почему я всё ещё не сеньор?», «Чего мне не хватает?», «Как перейти дальше?». Это период роста и некоторого внутреннего напряжения, когда кажется, что недооценивают, иногда что слишком много давят. Важно понимать, что это естественный этап, когда расширяется кругозор, учатся смотреть на систему шире.

Становление миддлом не является формальной процедурой, здесь нет как таковых экзаменов, и обычно происходит постепенно - задачи всё более сложные, получают обратные связи, улучшают качество кода, начинают понимать, как работает команда.

Развитие миддла - это процесс глубокого погружения, когда начинают изучать не только языки программирования, но и более сложные темы, а код должен быть стабильным, масштабируемым и безопасным. На уровне миддла можно уже выбрать конкретное направление и развиваться в нём, к примеру, фронтенд или бэкенд. В зависимости от направления, требования и задачи будут отличаться, но общий уровень ответственности остаётся одинаковым.

На уровне миддла уже повсеместно ожидается знание языков, фреймворков, опыта работы, знания принципов чистого кода, участия в реальных проектах, умения читать чужой код. Как правило, общее, что требуется от джуниора - знание теории, а от миддла - практика. Задачи миддла уже не ограничиваются простыми багами, часто это реализация крунпых фич, работа с несколькими компонентами одновременно, рефакторинг, код-ревью, внедрение сервисов, помощь джунам, и даже предложения по изменению в архитектуре. Это полноценная часть системы, которая влияет на качество продукта.

Не стоит переживать, если миддлом не знать, как масштабировать систему на миллион пользователей, как писать собственные ORM или фреймворки, варианты архитеткурных решений, теории управления, стратегических решений или деталей облачных платформ вроде AWS, GCP, Azure. Это задачи сеньора, а сейчас нужно просто уметь выполнять хорошо свою часть работы.

Сеньор​

Когда человек проходит через этапы джуниора и миддла, накапливает опыт, знания и уверенность - он становится сеньором. Это уже не просто разработчик, а эксперт, на плечи которого ложится ответственность за техническую часть проекта, а иногда и за команду. Может быть, и даже за стратегию развития продукта.

Сеньором обычно называют специалиста с 5-10 годами опыта в индустрии, который понимает, как устроены системы в целом, может принимать решения, которые влияют на долгосрочное развитие продукта, умеет не только писать код, но и объяснять, почему выбрано именно такое решение, влияет на выбор технологий, архитектуру, процессы и подходы в команде, и главное - руководит людьми или хотя бы умеет делегировать задачи и помогать другим расти.

Важно понимать, что в IT не работает принцип других отраслей, где начальником или старшим может быть человек менее компетентный, чем нижестоящий, здесь сеньор это уровень, на котором человек перестаёт быть «исполнителем» и становится архитектором, наставником и стратегом.

Слово старший здесь означает не возраст, а уровень ответственности и влияния. Если джун отвечает за выполнение конкретной задачи, а миддл - за модуль или фичу, то сеньор несёт ответственность за всю систему. Он принимает участие в обсуждении архитектуры, оценивает риски и возможные проблемы заранее, делает так, чтобы система была не только рабочей, но и масштабируемой, поддерживаемой, безопасной, может работать напрямую с менеджерами, бизнес-аналитиками и руководителями.

Как себя чувствуют сеньоры? Буду сеньором, как правило, ощущается совсем другой уровень давления - теперь все ждут не только правильного выполнения задачи, но и правильных решений. Теперь уже зачастую не получится просто спросить «А как вы обычно делаете?» - теперь все вопросы задают уже сеньору. Многие сеньоры говорят, что чувствуют большую нагрузку из-за необходимости быть в курсе изменений, принимать сложные решения и брать на себя ответственность за ошибки. Но при этом они получают гораздо больше уважения, автономии и конечно финансовой стабильности. Также часто возникает чувство внутреннего конфликта между желанием писать код и необходимостью управлять процессами. Кто-то уходит в техническую экспертизу, кто-то в роль менеджера или техлида.

Становление сеньора не является прямой дорогой, и для этого нужно решать именно сложные задачи, учиться у других, читать код других людей, писать документацию, иметь опыт наставничества и изучения архитектуры. В какой-то момент можно заметить, что стали спрашивать совета, и что мнение учитывается при выборе технологий.

Поэтому здесь два основных пути:

  • технический путь - углубление в технологии, системное проектирование, облачные архитектуры, DevOps, безопасность, автоматизация;
  • лидерский путь - переход к управлению людьми, проектами, командами.

Должности бывают разные - от программистов до инженеров, архитекторов, проектировщиков, где-то это может быть просто должность разработчика с надбавкой уровня сеньора, а где-то руководитель департамента.

На уровне сеньора ждут глубоких знаний в одном или нескольких языках программирования, опыта работы с масштабируемыми системами или высоконагруженными проектами, знания архитектурных паттернов, понимания DevOps, контейнеризации, участия в проектировании систем, выборе технологий, опыта в управлении командой или хотя бы в наставничестве, умения читать и писать техническую документацию, коммуникационных навыков и понимания бизнес-задач.

Задачи соответствующие - это может быть разработка архитектуры нового сервиса, или рефакторинг существующего, настройка CI/CD и автоматизации тестирования, управление зависимостями и техническим долгом, обучение, согласование, прогнозирование и консультирование.

Онбординг​

Onboarding (онбординг) — это процесс адаптации нового сотрудника в компании. Он включает в себя все мероприятия, направленные на то, чтобы помочь новому сотруднику быстро освоиться, понять корпоративную культуру, получить необходимые знания и инструменты для эффективной работы. Крупные компании серьёзно относятся к этой процедуре, ведь если хорошо принять сотрудника, это увеличит его вовлечённость, снизить текучку кадров и создаст позитивное первое впечатление о компании.

Когда новичок попадает в новую среду, он сталкивается с множеством новых людей, процессов, инструментов и задач. Без должной поддержки этот период может быть стрессовым и привести к тому, что сотрудник уйдёт через несколько месяцев. Поэтому эффективный онбординг направлен на снижение времени выхода на продуктивность, укрепление доверия между сотрудником и работодателем, повышение удовлетворённости работой, создание культуры открытости и постоянного развития и конечно предотвращение преждевременного ухода ценных специалистов.

Как правило, онбординг включает несколько этапов:

  1. Административная адаптация. Это самая формальная часть, когда новому сотруднику нужно пройти юридические и технические процессы, необходимые для начала работы:
    • оформление документов;
    • получение оборудования;
    • настройка учётных записей и доступа к ресурсам;
    • знакомство с внутренними системами и политиками компании.

Хорошие компании организовывают всё так грамотно, что заранее готовят всё необходимое к первому дню, чтобы сотрудник сразу мог сосредоточиться на работе, а не на поиске паролей или установке софта.

  1. Знакомство с командой и продуктом. Важно, чтобы новый сотрудник понял, кто есть кто в команде, как работает компания и какие задачи решает её продукт.

Для этого проводят встречи с коллегами и руководителями, обзор структуры компании и роли своей команды в ней, изучение продуктовой стратегии, целевой аудитории и бизнес-модели, а также знакомство с текущим проектом. На этом этапе особенно важно пояснить контекст - зачем делается продукт, кто его использует, и как именно новый сотрудник будет влиять на его развитие.

  1. Обучение и развитие. Новый сотрудник должен получить знания, необходимые для выполнения своих обязанностей:

    • технические навыки (кодовая база, регламенты, архитектура и используемые решения);
    • внутренние процессы (как создавать задачи, работать с Git);
    • работа с документаций (где хранится, как пользоваться и править);
    • возможности для обучения - доступ к курсам, книгам и тренингам.

  2. Обратная связь и менторство. Компании, которые ценят своих сотрудников, вводят регулярные встречи с менеджером или ментором, так как получение обратной связи очень важно для быстрого развития.

Компания обозначает руководителя, и назначает ментора - опытного коллегу, который помогает разбираться с вопросами, объясняет тонкости и поддерживает. Кроме этого, проводятся регулярные встречи с руководством для обсуждения прогресса, трудностей и планов. На ошибки здесь важно указывать без мотивации, именно поэтому нужен наставник, который на ранних этапах поможет неуверенному новичку разобраться. На практике онбординг используется по лучшим вариациям - с использованием чек-листа (подробного списка задач), временного напарника, набора материалов для новичка, а также обучающие видео и гайды.

Крупные корпорации зачастую создают именно иллюзию того, что работа в компании прекрасна, а все сотрудники приветливы и заботливы, будто на новичка не плевать.

Стажировка​

Первое, с чем столкнётся начинающий айтишник - с отсутствием опыта и требованием в вакансиях многих лет опыта с какими-то определёнными технологиями. После этого возникает вопрос - а где этот опыт набирать?

Ответ - набираться опыта стажёром или ассистентом. Если вы сорокалетний новичок, с семьей, которую надо кормить - будет сложно в финансовой части. Стажёрам либо не платят, либо платят совсем немного, поэтому здесь нужно иметь хотя бы какой-то запас средств для обеспечения существования.

Стаж - это период практической работы. Стаж может быть оплачиваемым и неоплачиваемым, и не обязательно придерживаться подхода указания в резюме только трудового стажа в соответствии с трудовой книжкой - нужно указывать и стажировки. Ведь это всё служит для приобретения опыта, развития навыков и понимания реального рабочего процесса.

Стажировка — это форма обучения на практике, когда человек (стажёр) временно работает в компании под руководством опытных специалистов. Это позволяет не только применить знания, полученные ранее, но и погрузиться в корпоративную культуру, увидеть, как работают настоящие проекты, и начать формировать свою профессиональную сеть. В IT-сфере стажировка особенно важна, потому что теория программирования — лишь малая часть того, что нужно знать для успешной работы. Реальные задачи, коммуникация в команде, использование Git, Jira, CI/CD, работа с чужим кодом — всё это можно по-настоящему понять только в условиях реальной разработки.

Зачем нужна стажировка и чем она полезна?

  1. Получить реальный опыт, а не только учебные проекты.
  2. Разобраться в технологиях, используемых в индустрии.
  3. Узнать, как работают процессы, как выполняется планирование, анализ, разработка, тестирование, релиз, поддержка.
  4. Понять, подходит ли сфера, направление или компания.
  5. Наладить связи с коллегами, которые могут стать рекомендателями.
  6. Укрепить портфолио, даже если проект закрытый - можно указать свой вклад, без раскрытия конфиденциальной информации.
  7. Подготовиться к первому собеседованию, ведь стажировка будет уже в резюме.

Кроме того, стажировка поможет новичку упростить период адаптации, придаст психологическую уверенность, благодаря чему человек будет чувствовать себя частью сообщества, понимать язык профессионалов, и видеть, как выглядит развитие изнутри. Формальная стажировка - это официально организованная программа, часто с контрактом, расписанным графиком, ментором и иногда с оплатой. Такие программы проводят крупные компании, стартапы, образовательные платформы и университеты.

Примеры - программы стажировок в Google, Яндекс, Т-Банк (Тинькофф), JetBrains, учебные центры, предлагающие стажировки после курсов, и программы вроде Яндекс Практикум, Stepik Internship и другие.

Формальная стажировка обеспечит официальное подтверждение опыта, чётко обозначенный план развития, даст высокий шанс остаться в компании после стажировки и даже возможность получения оплаты.

Неформальная стажировка же менее структурированный путь, подразумевающий, к примеру, участие в open source, помощь знакомым с проектами, волонтёрство, или стажировка «по знакомству» без формального оформления.

Это более гибко, без бюрократии и возможность начать всё максимально быстро, но не даёт гарантий, не подтверждается официально, а также имеет сложности в получении обратной связи.

Для многих стажировка становится первым шагом к трудоустройству. Особенно если человек показывает хорошие результаты, умеет работать в команде и хочет развиваться. Зачастую под «желанием развиваться» работодатели подразумевают готовность работать и учиться во внерабочее время, инвестируя личное время в саморазвитие.

Как стажировка может привести к постоянной работе?

  1. Знание продукта и процессов - обучение уже не требуется.
  2. Доказательство надёжности - уже знают, доверяют и ценят.
  3. Есть внутренние рекомендации - коллеги могут дать положительный отзыв.
  4. Экономия времени для HR - зачем искать нового кандидата, когда вот он!

Поэтому важно воспринимать стажировку как «пробный период», во время которого человек должен показать себя с лучшей стороны.